home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 137_01 / feb84col.ddj < prev    next >
Text File  |  1980-01-01  |  20KB  |  535 lines
  1. .pl 60
  2. .po 0
  3. ..
  4. .. "The C/Unix Programmer's Notebook"
  5. ..
  6. .. DDJ Column #2        as of 19-Sep-83
  7. .. (C) 1983 Anthony Skjellum.   All rights reserved.
  8. .. For publication in DDJ
  9. ..
  10. ..
  11. .. file (DDJCOL2.WS)        created:  24-Nov-83
  12. ..                updated:  24-Nov-83
  13. ..                updated:  25-Nov-83
  14. ..
  15. ..                completed: 25-Nov-83
  16. ..
  17. .he "C/Unix Programmer's Notebook" by Anthony Skjellum. (C) 1983. For 2/84 DDJ.
  18.  
  19.                                Introduction
  20.  
  21. ..
  22.     In the first installment of this column,  I proposed a standard for 
  23.  
  24. the  layout  of C code (see DDJ #84,  October,  1983.)  Significant  reader 
  25.  
  26. response  was received concerning this subject.   The vast majority of  the 
  27.  
  28. letters received were in favor of the concept of a C layout  standard.   In 
  29.  
  30. this column, I will present reader comments concerning the layout standard, 
  31.  
  32. and discuss some modifications and additions to the proposed standard based 
  33.  
  34. on reader suggestions.  
  35.  
  36. ..
  37.     Some  comments  were  also  received concerning  my  discussion  of 
  38.  
  39. runtime library and linkage format incompatibilities.   Discussion of these 
  40.  
  41. points will be left for a future column.
  42.  
  43.                   Modifying the Proposed Layout Standard
  44.  
  45.                         I. Questions of White Space 
  46.  
  47. ..
  48.     Several readers took exception to a particular point concerning the 
  49.  
  50. proposed layout standard.   This was point 4f. which states "No white space 
  51.  
  52. character  is  placed between a keyword (e.g.  if)  and  its  parenthesized 
  53.  
  54. argument."  David D. Clark of State College, Pennsylvania, writes:
  55.  
  56. ..
  57.     "In  general,  I like your coding standard  suggestions.   My  only 
  58. strong  objection  is your idea to leave out spaces between reserved  words 
  59. [and their arguments].  It makes them look like function invocations."
  60.  
  61.     Tim Smith of Evanston, Illinois, notes:
  62.  
  63. ..
  64.     "...I  think  that a single space between a function name  and  the 
  65. initial opening parenthesis, or after "if's" and "elses", looks better..."
  66.  
  67.     Guy Scharf of Mountainview, California writes:    
  68.  
  69. ..
  70.     "4f.   I  have a strong preference to always put a space between  a 
  71. reserved word (e.g.  if,  while) and its parenthesized argument.  This adds 
  72. legibility for me."
  73.  
  74.     Finally, Charlie Brady of New South Wales, Australia, writes:
  75.  
  76. ..
  77.     "The  only real beef I have with you is the formatting of  keywords 
  78. and  their parenthetical expressions.   I can see no reason to depart  from 
  79. Kernighan  and  Ritchie  on  this  point,  and  a  number  of  reasons  for 
  80. maintaining  their  convention.   Firstly,  a  flow  control  construct  is 
  81. semantically distinct from a function call,  and a formatting difference is 
  82. a  reasonable  way  of  distinguishing  them.    Secondly,  the  formatting 
  83. difference  simplifies  the  use  of  a  text  editor  for  such  tasks  as 
  84. constructing structure charts.   Third, your recommendation departs from at 
  85. least  three  extant recommended standards,  namely Kernighan and  Ritchie, 
  86. Thomas  Plum  (C Standards and Guidelines,  Plum-Hall 1981)  and  Tim  Lang 
  87. (Formatting C,  AUUGN Vol 4,  No 1, Jan 1982. Enclosed)."  (I want to thank 
  88. Mr.  Brady for including a copy of the Lang article with his letter.  The C 
  89. standard proposed there is very compatible with the one I have proposed.)  
  90.  
  91. ..
  92.     After considering the above remarks,  I have come to the conclusion 
  93.  
  94. that  the space really does serve a useful purpose.   Therefore,  I suggest 
  95.  
  96. that  point 4f.  should be changed to read:  "A single white  character  is 
  97.  
  98. (optionally)  placed  between  a keyword (e.g.  if) and  its  parenthesized 
  99.  
  100. argument."  (Making the white space character optional is another point for 
  101.  
  102. debate.)  I think it should be optional,  but recommended.   I don't  think 
  103.  
  104. that  adding a space for function call invocations would be beneficial,  as 
  105.  
  106. suggested by Mr. Smith. 
  107.  
  108. ..
  109.     Another   question  concerning  white  space  insertion  comes   in 
  110.  
  111. connection with argument lists.  The original standard does not indicate if 
  112.  
  113. spaces  should  be  included.   It is my opinion that  a  comma  should  be 
  114.  
  115. directly adjacent to the argument that it follows,  and that a single white 
  116.  
  117. space should follow each comma to add legibility.  I am also convinced that 
  118.  
  119. parentheses  should be adjacent to the argument(s) they enclose.   Thus (in 
  120.  
  121. agreement with Tim Lang's article mentioned above) I would write:
  122.         
  123.         x = atan(sin(y));        
  124.  
  125. and not
  126.  
  127.         x = atan(  sin( y ) );  
  128.  
  129. ..
  130.     Yet another point not previously mentioned is that binary operators 
  131.  
  132. should be delimited by white space.   Thus,  the following statement  lacks 
  133.  
  134. sufficient white space:
  135.  
  136.         v = sin(ln(1.0+x));
  137.  
  138. while this expression is properly formed:
  139.  
  140.         v = sin(ln(1.0 + x));
  141.  
  142. ..
  143.     Finally,  section  4  needs  to  be  updated  to  include  a  style 
  144.  
  145. specification for pointer references.   I think that that operators '.' and 
  146.  
  147. '->'  should not be delimited by spaces from the objects which they act on.  
  148.  
  149. This point and the three above are formalized in Figure I.  as additions to 
  150.  
  151. section 4.
  152.  
  153. .pa
  154.               ------------------FIGURE I.--------------------
  155.  
  156.     (Under section 4)
  157.  
  158.          b.  Binary operators (e.g.  +,  -, / but not '->' and '.') and 
  159.                  assignment operators (eg =, *=, &=) are delimited by white 
  160.                  space.
  161.  
  162.          g.  Parentheses  should be adjacent to the  argument(s)  which 
  163.                  they enclose.  
  164.  
  165.          h.  A comma is bound to the argument which preceeds and should 
  166.                  be followed by a single space.
  167.                  
  168.  
  169.          i.  Operators   such  as  '->'  and  '.'  (used   in   pointer 
  170.                  references)  directly  bind  to their  arguments  with  no 
  171.                  intervening spaces.
  172.  
  173.           ---------------------END FIGURE I.--------------------         
  174.  
  175.  
  176. ..
  177.     The  Lang article points out a circumstance under which  point  9g. 
  178.  
  179. need  not  be  followed.   This occurs when  very  complicated  conditional 
  180.  
  181. expressions of the form "keyword (expr)" are split over several lines.  For 
  182.  
  183. example,  instead  of using a crowded expression as illustrated in  Example 
  184.  
  185. 1a.,  a  more  readable  form is selected (see Example 1b.)  Note  that  in 
  186.  
  187. Example 1b.  that the parentheses are placed on lines by themselves,  since 
  188.  
  189. they  bracket  a  multiline  expression,   much  like  braces  enclose  the 
  190.  
  191. statements of a block.
  192.  
  193.            --------------------Example Ia.---------------------
  194.  
  195.         if((a  == 1) && (b == 2) && (c == 3) && ((d == 4) || (d == 5)))
  196.         {
  197.             /* operations performed if conditional true */
  198.             ...
  199.         }
  200.  
  201.           --------------------End Example Ia.--------------------
  202.  
  203.            --------------------Example Ib.---------------------
  204.  
  205.         if    /* we make multi-line expression look like a block */
  206.         (
  207.             (a == 1) &&
  208.             (b == 2) &&
  209.             (c == 3) &&
  210.             ((d == 4) || (d == 5))
  211.         )
  212.         {
  213.             /* operations performed if conditional true */
  214.             ...
  215.         }
  216.  
  217.           --------------------End Example Ib.--------------------
  218.  
  219. ..
  220.     Another  point  of  minor  objection  was  the  tabulation   method 
  221.  
  222. specified  by  the  standard (point 1a.).   Steve Newberry  of  Los  Altos, 
  223.  
  224. California, states:
  225.  
  226. ..
  227.     "Upon one point I do feel compelled to argue with you,  and that is 
  228. the  tab convention:   The DEPTH of the tab stop on a given page is of  far 
  229. less  significance to the readability of that page than is the  CONSISTENCY 
  230. of  the depth.   I REALLY don't want to use different size tabs on the same 
  231. page."  
  232.     
  233.     Tim Smith writes:
  234.  
  235.     "I personally follow most all of his suggestions on how to actually 
  236. format the code on the line and page,  with only two exceptions.   I ALWAYS 
  237. use 4-space tab stops..."  
  238.  
  239. ..
  240.     I  agree  that  having a single tab size is the preferable  way  to 
  241.  
  242. write  C  code.   Standard tabs give more openness to the  code,  and  make 
  243.  
  244. various  parts  of a program easier to pick out.   My rationale  for  large 
  245.  
  246. horizontal  tabbing